Many software development tools are available today for use by software designers (or “developers”) in creating various types of software applications. Software “designers” and “developers” are used interchangeably herein, and generally refer to anyone involved with using a software development tool (or “authoring tool”) for authoring a software program. Authoring may include coding, designing, and/or otherwise creating or modifying the software program. A software program, as used herein, generally refers to any software program that may be executed by a processor (or interpreter of some type) in order to perform operations defined by the instructions of the software program, including as an example presenting a user interface to a display. One example of such a software program is a web page, which may be defined by one or more source files that may be coded in markup language, such as HTML, XML, etc., style sheet language (e.g., Cascading Style Sheet language), scripting language (e.g., JavaScript), and/or other underlying page source code that may be read and interpreted by a browser to generate a corresponding output presentation of the web page to a display.
In a software development environment, a developer may interact with a software development tool for writing code, compiling the code, testing or debugging the code, and packaging the resulting program for deployment in a run-time environment. The software development tool may be implemented as a software application that is stored to a computer-readable medium and executed by a computer processor to perform the tasks associated with aiding a developer in the development of a software program. As one example, an integrated development environment (IDE) is commonly used for developing software programs. In general, an IDE is a programming environment that has been packaged as a software application, typically including a code editor, a compiler, a debugger, and a graphical user interface (GUI) builder. The IDE may be a stand-alone application or may be included as part of one or more existing and compatible applications. IDEs provide a user-friendly framework for many modern programming languages, such as Visual Basic, Java, and PowerBuilder. IDEs for developing source code for web pages, such as markup language (e.g., HTML, XML, etc.) code, CSS code, and/or JavaScript code, are among the most commonly used.
Thus, IDEs provide software authoring tools that allow a developer e.g., a web developer) to create web pages, websites, interactive applications, and the like for use by end users (e.g., visitors to websites). Various IDEs exist in the current marketplace, such as DREAMWEAVER®, available from Adobe Systems Incorporated, and FRONTPAGE®, available from Microsoft Corporation. DREAMWEAVER is one example of a software authoring tool that allows web developers to design Hypertext Markup Language (HTML) web pages in both a code editor and a graphical-based design time environment. DREAMWEAVER also allows the developer to design in other markup languages, such as, for example, Extensible Markup Language (XML), Extensible HTML (XHTML), Active Server Page (ASP), COLDFUSION™ Markup Language (CFML™), and the like.
Many software application authoring tools, as may be provided by an IDE, are available today for use by software developers in creating various types of software programs, including as examples such software code authoring tools as ADOBE® DREAMWEAVER® and MICROSOFT® FRONTPAGE®. Certain authoring tools, such as ADOBE® DREAMWEAVER®, allow a developer to create a document in an environment that includes both a text-based code view and a graphical-based design view. The code view renders the source code (e.g., markup language code) as text in a portion of the screen and allows the developer to see and manipulate the source code in the document file. For example, the developer may write and edit HTML, Cascading Style Sheets (CSS), and/or scripting language (e.g., javaScript) code in the code view. The design view (or “display view”), on the other hand, is a What You See Is What You Get (WYSIWYG) view of the document that allows the user to visually manipulate the interpreted and graphically laid-out version of the document, such as, for example, by dragging, dropping, cutting, and pasting visual components. For instance, techniques similar to those employed by browsers may be employed for presenting the resulting output presentation (e.g., web page) of the underlying source code, wherein the developer may manipulate such output presentation within the design view. As the developer works, changes to the document are reflected in both the code view and the design view.
Once a designer creates web page source code (which may be referred to as a “source page”), such web page source code is typically stored to a web server that is accessible by clients via a communication network, such as the Internet. The clients may access the web server and download the source code, which a browser executing on the client's computer interprets to generate a corresponding output presentation, as is well known in the art.
Software programs, such as web page source code files, may comprise various types of code, including as examples structural code, stylistic code, and behavioral code. In general, “structural code” refers to instructions that define the structure of the run-time program, such as the structure of the presentation output of a web page by a browser. As an example, markup language code, such as HTML, can be used to define the structure of a presentation output document that is generated by a web browser when the browser is interpreting such markup language code. HTML and its successor languages, such as XHTML, have been generally used to define the structure of web pages from the very early stages of the well-known World Wide Web (the “web”) portion of the Internet. Traditionally, markup tags defining the structure, such as those defining headings, paragraphs, lists, tables, and the like (i.e., structural markup) are coded using a markup language, such as HTML, in the underlying source code of a web page.
In general, “stylistic code” refers to instructions that define the style of the run-time program, such as the style of the presentation output of a web page by a browser. Again, as an example, a markup language, such as HTML or XHTML, may be used to define the style of a web page that is to be generated by a web browser when the browser is interpreting such markup language code. Traditionally, markup tags defining the style of the page content presented by a browser, such as bold, underlined, font, font size, and the like (i.e., stylistic markup) are coded using a markup language, such as HTML, in the underlying source code of a web page.
In general, “behavioral code” refers to instructions that define the functional run-time behavior of the program. Such functional run-time behavior may define how the program is to react to certain events, such as user input events, etc. As examples, the behavioral code may define certain operational functions that are to be performed upon a page being loaded by a browser (e.g., an “onload event”), the behavioral code of a program may define functional operations to be performed by the program responsive to a user moving a cursor over a particular element being shown on a user interface (e.g., a “mouse-over event”), and/or the behavioral code of a program may define functional operations to be performed by the program responsive to a user clicking a button on a user interface. Such behavioral code is commonly coded using a scripting language, such as JavaScript, and/or via the use of a markup language (e.g., HTML) event attribute, like onclick, onmouseover, etc.
Accordingly, a structural arrangement of a run-time output presentation (e.g., of a web page by a browser) may be defined by structural code of a source code file, the stylistic presentation of the page (e.g., the visual look, such as color, font, etc.) may be defined by stylistic code of the source code file, and the behavior of the page (e.g., functional operation responsive to certain events, such as user input) may be defined by behavioral code of the source code file. Traditionally, an underlying source code file may comprise each of the structural code, stylistic code, and behavioral code for a program. For instance, in a source file for a web page, markup tags defining the structure, such as those defining headings, paragraphs, lists, tables, and the like (i.e., structural markup), may be included in an HTML document along with markup tags defining the style and appearance of the page content, such as bold, underlined, font, font size, and the like (i.e., stylistic markup), and behavioral code such as JavaScript and/or other behavioral code may additionally be included in such HTML source file. To enhance the appearance and operational functionality of web pages, developers are including increasing amounts of stylistic markup and behavioral code in such web page source code.
However, with all of such stylistic markup and behavioral code being included along with the structural coding of the document, the underlying source code document (e.g., HTML document) for even the most basic web page often becomes undesirably long and complicated, which results in increased difficulty in creating and editing the markup language documents defining the web pages. Further, the interleaved inclusion of the structural code, stylistic code, and behavioral code creates difficulty and inefficiency for developers in recognizing and analyzing each of these portions of the program. For instance, it may be difficult for a developer to recognize and analyze the structure of a page because of the added “noise” in the underlying source document that results from the further inclusion of the stylistic and behavioral code. In addition, a source code file containing structural code, stylistic code, and behavioral code is often undesirably large and is undesirably inefficient from a code reuse point of view (e.g., does not readily permit the reuse of stylistic and/or behavioral code across multiple pages).
Thus, separating structural code from stylistic code and/or behavioral code is emerging as a desirable best practice in software development. For example, with regard to separating out stylistic code, style sheet languages, such as Cascading Style Sheets (CSS), have been developed to aid in defining the styling for a given document, such as a web page. CSS is a popular style sheet language commonly used to describe the style/presentation (e.g., colors, fonts, layout, etc.) of documents written in markup language. By using a markup language (e.g., HTML) and style sheet language (e.g., CSS) together, web designers are able to advantageously separate a web page's structure and content (written in markup language) from its style (or “presentation formatting”), written in style sheet language. For instance, using CSS, developers are generally able to define the style of an entire web document by defining styles in a separate CSS file, and applying those styles to the content and structure defined by a markup language file. Because the style is applied to the content, one style may be applied to multiple sections of the markup language document, thus reducing the size of the coding for defining the resulting web page. Moreover, developers may change the entire appearance of a web page by changing the CSS without effecting the content of the page.
Style sheets, such as CSS, are commonly employed to help readers of web pages (e.g., browsers) to define visual layout of a web page's content, such as colors, fonts, layout, and other aspects of document presentation. In this manner, the style sheet may be designed primarily to enable the separation of document structure and content (written in HTML or a similar markup language, e.g., in a main file) from document style (written in (CSS). Thus, the main HTML file for a web page may be authored to define certain structure and content e.g., text, images, etc.) of an output presentation document that is to be generated when the web page is interpreted by an interpreter program (such as a client browser), and the main HTML file may reference one or more style sheets that define the visual layout of such content that is desired to be generated within the output presentation document. Such use of style sheets are well known in the art.
As a further example, with regard to separating out behavioral code, such as JavaScript code, a separate behavioral code file (e.g., JavaScript file) may be created that contains the code defining the behavior of the given software program, such as a web page. For instance, a scripting language file, such as JavaScript (JS) files, are commonly employed to provide functions that may be executed during run-time of a web page by a browser to further define the behavior of the output presentation document (e.g., web page) presented by the browser. Such use of scripting language files are also well known in the art. Thus, a main web page document (e.g., main HTML document) may contain structural code (and certain content) for the web page, and the main web page document may reference one or more related files, such as style sheet files that contain stylistic code and/or behavioral files (e.g., scripting language files) that contain behavioral code for imparting certain behavior/functionality for the output presentation document presented by the browser.
Separating behavior from structure in web page documents is emerging, for example, as a recommended practice for maintaining clean semantic HTML markup that is free of any attributes or script that introduces custom behaviors. A desire has thus been recognized for having any custom behaviors that are introduced into an HTML page to come from external files that unobtrusively attach/bind the behaviors to elements within the semantic markup. Like the practice of separating style from structure, this separation of behavior from structure may provide one or more benefits, some of which may include:
a) the ability to make incremental modifications to the HTML markup structure or the behavior code independently without having to modify the other;
b) because the behavior implementation is externalized, it can be shared across multiple HTML pages, so the bandwidth necessary to view these pages is reduced since the files related to the behaviors can be downloaded and cached by the browser once. This also results in smaller HTML pages since the behavior code is not duplicated within the actual markup itself; and
c) since the HTML markup is smaller and semantic, it may also be easier to read, which may aid accessibility with screen readers, search engine web crawlers, and browsers or other user agents that do not necessarily support the behaviors implemented for the page.
With regard to separating behavioral code from structural code, a desire has been recognized for an “Unobtrusive JavaScript” technique. In general, such Unobtrusive JavaScript refers to the practice of separating out any JavaScript behavior code from a page's content structure and presentation. With Unobtrusive JavaScript, only <script> tags that include external JavaScript files are allowed within the source document being coded. The general goal of such Unobtrusive JavaScript technique is to eliminate the use of any <script> tags with inline JavaScript and the use of any HTML behavioral/event attributes, like onclick, onmouseover, etc., that make use of JavaScript from within the content markup itself and externalize this code in a separate JavaScript file which gets included by a <script> tag with a “src” attribute. Thus, these externalized behaviors will get programmatically attached to the elements at some point during the document loading process, most likely after the window onload event fires, with the use of the DOM APIs which allow event handlers to be added/removed programmatically.
Traditionally, achieving such separation of structural code and behavioral code is coding-intensive for developers. For instance, developers have traditionally been required to manually identify in-line behavioral code (e.g., JavaScript code, markup language behavioral event attributes, etc.) within a source code document that is desired to be extracted. In addition, developers are further required to manually write code to unobtrusively attach/bind the extracted behaviors to elements within the source code document. The developers would then have to manually strip out all of the behaviors that were externalized from the source code document, and include the file containing the code that does the attaching/binding. Unobtrusive attachment/binding of behaviors typically involves writing code that gets triggered after the document's onload event notification is fired. This code typically makes DOM calls that either attach event handlers or set attributes/properties on elements within the HTML document. Unfortunately, writing this code is sometimes difficult for, or beyond the scope of, many developers, such as those who may use software authoring tools like DREAMWEAVER who are accustomed to attaching behaviors to page elements visually with a user interface.
Accordingly, a desire exists for an improved system and method for extracting behavioral code from a source code document.